home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-piscitello-ftp-bigports-00.txt < prev    next >
Encoding:
Text File  |  1993-05-04  |  6.2 KB  |  213 lines
  1.  
  2. IETF                                                       Page 1
  3. April 30, 1993   FTP Operation Over Big Address    Internet Draft
  4.  
  5.  
  6.      FTP Operation Over Big Address Records (FOOBAR)
  7.  
  8.  
  9.          David M. Piscitello
  10.                Bellcore
  11.           dave@sabre.bellcore.com
  12.  
  13.  
  14.                Status of this Memo
  15.  
  16. This document is an Internet Draft.  Internet Drafts are working
  17. documents of the Internet Engineering Task Force (IETF), its
  18. Areas, and its Working Groups. Note that other groups may also
  19. distribute working documents as Internet Drafts.
  20.  
  21. Internet Drafts are draft documents valid for a maximum of six
  22. months. Internet Drafts may be updated, replaced, or obsoleted by
  23. other documents at any time.  It is not appropriate to use
  24. Internet Drafts as reference material or to cite them other than
  25. as a "working draft" or "work in progress."
  26.  
  27. Please check the Internet Draft abstract listing contained in the
  28. IETF Shadow Directories (cd internet-drafts) to learn the current
  29. status of this or any other Internet Draft.
  30.  
  31.  
  32.               Introduction
  33.  
  34. This Internet-Draft specifies a method for assigning long
  35. addresses in the HOST-PORT specification for the data port to be
  36. used in establishing a data connection for File Transfer
  37. Protocol, FTP (RFC959, 1985). This is a general solution,
  38. applicable for all "next generation" IP alternatives, and can
  39. also be extended to allow FTP operation over transport interfaces
  40. other than TCP.
  41.  
  42.  
  43.                 Abstract
  44.  
  45. This paper describes a convention for specifying longer addresses
  46. in the PORT command.
  47.  
  48.  
  49.              Acknowledgments
  50.  
  51. Many thanks to all the folks in the IETF who casually mentioned
  52. how to do this, but who left it to me to write the internet
  53. draft. Special thanks to Rich Colella and Brian Carpenter who had
  54. the time and decency to comment on the initial draft:-)
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68. IETF                                                       Page 2
  69. Internet Draft               FOOBAR                April 30, 1993
  70.  
  71.  
  72. 1.  Background
  73.  
  74. The PORT command of File Transfer Protocol allows users to
  75. specify an address other than the default data port for the
  76. transport connection over which data are transferred. The PORT
  77. command syntax is:
  78.  
  79. PORT <SP> <host-port> <CRLF>
  80.  
  81. The <host-port> argument is the concatenation of a 32-bit
  82. internet <host-address> and a 16-bit TCP <port-address>.  This
  83. address information is broken into 8-bit fields and the value of
  84. each field is transmitted as a decimal number (in character
  85. string representation).  The fields are separated by commas.  A
  86. port command is thus of the general form "PORT
  87. h1,h2,h3,h4,p1,p2", where h1 is the high order 8 bits of the
  88. internet host address.
  89.  
  90. To accommodate larger network addresses, a new command, LPORT, is
  91. recommended. The LPORT command syntax is:
  92.  
  93.         LPORT <SP> <long-host-port> <CRLF>
  94.  
  95. The <long-host-port> argument is the concatenation of the
  96. following fields;
  97.  
  98.    + an 8-bit <address-family> argument (al)
  99.  
  100.    + an 8-bit <host-address-length> argument (hal)
  101.  
  102.    + a <host-address> of <host-address-length> (h1, h2, ...)
  103.  
  104.    + an 8-bit <port-address-length> (pal)
  105.  
  106.    + a <port-address> of <port-address-length> (p1, p2, ...)
  107.  
  108. The <address-family> argument takes the value of the protocol
  109. number of the "next generation" IP address (see Assigned Numbers,
  110. RFCxxxx, 1993), or generally speaking, a network layer protocol.
  111. The value of each field is broken into 8-bit fields and the value
  112. of each field is transmitted as an unsigned decimal number (in
  113. character string representation).  The fields are separated by
  114. commas.
  115.  
  116. A LPORT command is thus of the general form
  117.  
  118. LPORT al,hal,h1,h2,h3,h4...,pal,p1,p2...",
  119.  
  120. where h1 is the high order 8 bits of the internet host address,
  121. and p1 is the high order 8 bits of the port number (transport
  122. address).
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134. IETF                                                       Page 3
  135. April 30, 1993   FTP Operation Over Big Address    Internet Draft
  136.  
  137.  
  138. [Note: Brian Carpenter of Cern has observed that this
  139. representation is counter-intuitive for cases where the natural
  140. representation of part of an OSI network service access point
  141. address is binary coded decimal (BCD); for example, those with
  142. E.164 International numbers for ISDN included. Readers are
  143. encouraged to post comments if this is inappropriate.]
  144.  
  145.  
  146.  
  147. 2.  Rationale
  148.  
  149. An explicit address family argument allows the Internet community
  150. to experiment with a variety of "next generation IP" alternatives
  151. within a common FTP implementation framework. (It also allows the
  152. use of a different address family on the command and data
  153. connections.) An explicit length indicator for the host address
  154. is necessary because some of the IPNG alternatives make use of
  155. variable length addresses. An explicit host address is necessary
  156. because FTP says it's necessary.
  157.  
  158. The decision to provide a length indicator for the port number is
  159. not as obvious, and certainly goes beyond the necessary condition
  160. of having to support TCP port numbers. Given the increasingly
  161. "multi-protocol" nature of the Internet, it seems reasonable that
  162. someone, somewhere, might wish to operate FTP operate over
  163. Appletalk, IPX, and OSI networks as well as TCP/IP networks. (In
  164. theory, FTP should operate over *any* transport protocol that
  165. offers the same service as TCP.) Since some of these transport
  166. protocols may offer transport selectors or port numbers that
  167. exceed 16 bits, a length indicator may be desirable. If FTP must
  168. indeed be changed to accommodate larger network addresses, it may
  169. be prudent to determine at this time whether the same flexibility
  170. is useful or necessary with respect to transport addresses.
  171.  
  172.  
  173. 3.  Conclusions
  174.  
  175. The mechanism defined here is simple, extensible, and meets both
  176. IPNG and possibly multi-protocol internet needs.
  177.  
  178.  
  179. 4.  References
  180.  
  181. RFC959          Postel, J., and Reynolds, J., "File Transfer Protocol"
  182.         October 1985.
  183.  
  184. RFC1340         Reynolds, J., and Postel, J., "Assigned Numbers", July 1992
  185.         (probably does not include recently assigned IPv7 numbers).
  186.  
  187. RFC1123         Braden, R.,ed. "Requirements for Internet hosts -
  188.         application and support", 1989 October.
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200. IETF                                                       Page 4
  201. Internet Draft               FOOBAR                April 30, 1993
  202.  
  203.  
  204. 5.  Author Information
  205.  
  206. David M. Piscitello
  207. Bell Communications Research
  208. NVC 1C322
  209. 331 Newman Springs Road
  210. Red Bank, NJ 07701
  211. dave@mail.bellcore.com
  212.  
  213.